home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-bgp-bgp4ospf-interact-02.txt < prev    next >
Text File  |  1993-09-27  |  50KB  |  1,288 lines
  1.  
  2.  
  3. Network Working Group                                       K.  Varadhan
  4. INTERNET DRAFT                                                    OARnet
  5.                                                                 S. Hares
  6.                                                             NSFnet/Merit
  7.                                                               Y. Rekhter
  8.                                                                      IBM
  9.                                                            September 24,
  10. 1993
  11.                   BGP4/IDRP for IP---OSPF Interaction
  12.  
  13.  
  14. Table of Contents
  15.  
  16.  1.  Introduction ....................................................  2
  17.  2.  Reachability Information Exchange ...............................  4
  18.  2.1.  Exporting OSPF information into BGP/IDRP  .....................  4
  19.  2.2.  Importing BGP/IDRP information into OSPF ......................  6
  20.  3.  BGP/IDRP Identifier and OSPF router ID ..........................  7
  21.  4.  Setting OSPF tags, ORIGIN and PATH attributes ...................  9
  22.  4.1.  Semantics of the characteristics bits ......................... 11
  23.  4.2.  Configuration parameters for setting the OSPF tag ............. 12
  24.  4.3.  Manually configured tags ...................................... 12
  25.  4.4.  Automatically generated tags .................................. 13
  26.  4.4.1. Destinations with incomplete path information, PathLength =0 . 13
  27.  4.4.2. Destinations with incomplete path information, PathLength =1 . 13
  28.  4.4.3. Destinations with incomplete path information, PathLength >=1  14
  29.  4.4.4. Destinations with complete path information, PathLength =0 ... 14
  30.  4.4.5. Destinations with complete path information, PathLength =1 ... 15
  31.  4.4.6. Destinations with complete path information, PathLength >=1 .. 16
  32.  4.5.  Miscellaneous tag settings .................................... 16
  33.  4.6.  Summary of the TagType field setting .......................... 17
  34.  5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 17
  35.  6.  Changes from the BGP 3 - OSPF interactions document ............. 18
  36.  7.  Security Considerations ......................................... 19
  37.  8.  Acknowledgements ................................................ 19
  38.  9.  Bibliography .................................................... 20
  39.  10.  Appendix ....................................................... 21
  40.  11.  Author's Present Addresses ..................................... 22
  41.  
  42.  
  43. Status of this Memo
  44.  
  45.    This document is an Internet Draft, and can be found as draft-ietf-
  46.    bgp-bgp4ospf-interact.02.txt in any standard internet drafts
  47.    repository. Internet Drafts are working documents of the Internet
  48.    Engineering Task Force (IETF), its Areas, and its Working Groups.
  49.    Note that other groups may also distribute working documents as
  50.    Internet Drafts.
  51.  
  52.  
  53.  
  54. Varadhan, Hares, Rekhter                                        [Page 1]
  55.  
  56. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  57.  
  58.  
  59.    Internet Drafts are draft documents valid for a maximum of six
  60.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  61.    other documents at any time.  It is not appropriate to use Internet
  62.    Drafts as reference material or to cite them other than as a
  63.    ``working draft'' or ``work in progress.''
  64.  
  65.    Please check the I-D abstract listing contained in each Internet
  66.    Draft directory to learn the current status of this or any other
  67.    Internet Draft.
  68.  
  69. Abstract
  70.  
  71.    This memo defines the various criteria to be used when designing an
  72.    Autonomous System Border Routers (ASBR) that will run either BGP4 or
  73.    IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
  74.  
  75. 1.  Introduction
  76.  
  77.    This document defines the various criteria to be used when designing
  78.    an Autonomous System Border Routers (ASBR) that will run BGP4[BGP-4]
  79.    or IDRP for IP[IDRP] with other ASBRs external to the AS, and
  80.    OSPF[RFC1247] as its IGP.
  81.  
  82.    All future references of BGP in this document will refer to BGP
  83.    version 4, as defined in [BGP-4].  All reference to IDRP are
  84.    references to the Inter-Domain Routing Protocol (ISO 10747) which has
  85.    been defined by the IDRP for IP document [IDRP] for use in Autonomous
  86.    Systems.
  87.  
  88.    This document defines how the following fields in OSPF and attributes
  89.    in BGP/IDRP are to be set when interfacing between BGP/IDRP and OSPF
  90.    at an ASBR:
  91.  
  92.    IDRP came out of the same work as BGP, and may be consider a follow
  93.    on to BGP-3 and BGP-4.  Most fields defined in the interaction
  94.    between BGP and IDRP are named the same.  Where different, the IDRP
  95.    fields are shown separately.
  96.  
  97.            BGP/IDRP MULTI_EXIT_DISC
  98.  
  99.            BGP ORIGIN and AS_PATH/AS_SET     vs. OSPF tag
  100.            IDRP EXT_INFO and RD_PATH/RD_SET
  101.  
  102.            BGP/IDRP NEXT_HOP                 vs. OSPF Forwarding Address
  103.  
  104.            BGP/IDRP LOCAL_PREF               vs. OSPF cost and type
  105.  
  106.    IDRP contains RD_PATH and RD_SET fields which serves the same purpose
  107.  
  108.  
  109.  
  110. Varadhan, Hares, Rekhter                                        [Page 2]
  111.  
  112. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  113.  
  114.  
  115.    as AS_PATH and AS_SET fields for IDRP for IP.  In this document, we
  116.    will use the terms PATH and SET to refer to the BGP AS_PATH and
  117.    AS_SET, or the IDRP RD_PATH and RD_SET fields respectively, depending
  118.    on the context of the protocol being used.
  119.  
  120.    Both IDRP and BGP provide a mechanism to indicate whether the routing
  121.    information was originated via IGP, or some other means.  In IDRP, if
  122.    route information is originated by means other than an IGP, then the
  123.    EXT_INFO attribute is present.  Likewise, in BGP, if a route
  124.    information is originated by means other than an IGP, then the ORIGIN
  125.    attribute is set to <EGP> or <INCOMPLETE>.  For the purpose of this
  126.    document, we need to distinguish between the two cases:
  127.  
  128.         (a)  Route information was originated via IGP
  129.  
  130.         (b)  Route information was originated by some other means.
  131.  
  132.    The former case is realized in IDRP by not including the EXT_INFO
  133.    attribute, and in BGP by setting the BGP ORIGIN=<IGP>;  The latter
  134.    case is realized by including the EXT_INFO attribute in IDRP, and by
  135.    setting the BGP ORIGIN=<EGP>.  For the rest of the document, we will
  136.    use the BGP ORIGIN=<IGP> to refer to the former scenario, and BGP
  137.    ORIGIN=<EGP> to refer to the latter.
  138.  
  139.    One other difference between IDRP and BGP remains.  IDRP for IP
  140.    identifies an autonomous system by an identifier of variable length
  141.    that is syntactically identical to an NSAP address prefix, and
  142.    explicitly embeds the autonomous system number[IDRP].  BGP identifies
  143.    an autonomous system just by an autonomous system number.  Since
  144.    there is a one-to-one mapping between how an autonomous system is
  145.    identified in IDRP and in BGP, in this document, we shall identify an
  146.    autonomous system by its autonomous system number.
  147.  
  148.    For a more general treatise on routing and route exchange problems,
  149.    please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.
  150.  
  151.    This document uses the two terms ``Autonomous System'' and ``Routing
  152.    Domain.''  The definitions for the two are below:
  153.  
  154.    The term Autonomous System is the same as is used in the BGP
  155.    RFC[RFC1267], given below:
  156.  
  157.      ``The use of the term Autonomous System here stresses the fact
  158.      that, even when multiple IGPs and metrics are used, the
  159.      administration of an AS appears to other ASs to have a single
  160.      coherent interior routing plan and presents a consistent picture of
  161.      what destinations are reachable through it.  From the standpoint of
  162.      exterior routing, an AS can be viewed as monolithic: reachability
  163.  
  164.  
  165.  
  166. Varadhan, Hares, Rekhter                                        [Page 3]
  167.  
  168. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  169.  
  170.  
  171.      to destinations directly connected to the AS must be equivalent
  172.      from all border gateways of the AS.''
  173.  
  174.    The term Routing Domain was first used in [ROUTE-LEAKING] and is
  175.    given below:
  176.  
  177.           ``A Routing Domain is a collection of routers which coordinate
  178.           their routing knowledge using a single [instance of a] routing
  179.           protocol.''
  180.  
  181.      By definition, a Routing Domain forms a single Autonomous System,
  182.      but an Autonomous System may be composed of a collection of Routing
  183.      Domains.
  184.  
  185.      BGP, IDRP and OSPF have the concept of a set of reachable
  186.      destinations.  This set is called NLRI or Network Layer
  187.      Reachability Information.  The set can be represented either as an
  188.      IP address prefix, or an address, mask pair.  Note that if the mask
  189.      is contiguous in the latter, then the two representations are
  190.      equivalent.  In this document, we use the term `address/mask pair''
  191.      in the context of OSPF, and ``destination'' or ``set of reachable
  192.      destinations'' in the context of BGP or IDRP.
  193.  
  194.      This document follows the conventions embodied in the Host
  195.      Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
  196.      "SHOULD," and "MAY" for the various requirements.
  197.  
  198.      A minimal implementation of BGP/IDRP OSPF exchange MUST not
  199.      advertise a route containing a set of reachable destinations when
  200.      none of the destinations in the address/mask pair is reachable via
  201.      OSPF (section 2.1, bullet 3), MUST merge the PATH into a SET when
  202.      multiple exit points exist within the same autonomous system for
  203.      the same external destination (section 3), MUST set the OSPF tag
  204.      accurately (section 4).  This subset is chosen so as to cause
  205.      minimal havoc to the Internet at large.  It is strongly recommended
  206.      that implementors implement more than a minimalistic specification.
  207.  
  208. 2.  Reachability Information Exchange
  209.  
  210.    This section discusses the constraints that must be met to exchange
  211.    the set of reachable destinations between an external BGP/IDRP peer
  212.    from another AS and internal OSPF address/mask pairs.
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. Varadhan, Hares, Rekhter                                        [Page 4]
  223.  
  224. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  225.  
  226.  
  227.    2.1.  Exporting OSPF information into BGP
  228.  
  229.  
  230.       1.   The administrator MUST be able to selectively export
  231.            address/mask pairs into BGP/IDRP via an appropriate filter
  232.            mechanism.
  233.  
  234.            This filter mechanism MUST support such control with the
  235.            granularity of an address/mask pair.
  236.  
  237.            This filter mechanism will be the primary method of
  238.            aggregation of OSPF internal and type 1 and type 2 external
  239.            routes within the AS into BGP/IDRP.
  240.  
  241.            Additionally, the administrator MUST be able to filter based
  242.            on the OSPF tag and the various sub-fields of the OSPF tag.
  243.            The settings of the tag and the sub-fields are defined in
  244.            section 4 in more detail.
  245.  
  246.            o    The default MUST be to export no routes from OSPF into
  247.                 BGP/IDRP.  A single configuration parameter MUST permit
  248.                 all OSPF inter-area and intra-area address/mask pairs to
  249.                 be exported into BGP/IDRP.
  250.  
  251.                 OSPF external address/mask pairs of type 1 and type 2
  252.                 MUST never be exported into BGP/IDRP unless they are
  253.                 explicitly configured.
  254.  
  255.       2.   An address/mask pair having a non-contiguous mask MUST not be
  256.            exported to BGP/IDRP.
  257.  
  258.       3.   When configured to export an address/mask pair from OSPF into
  259.            BGP/IDRP, the ASBR MAY advertise the route containing the set
  260.            of reachable destinations via BGP/IDRP as soon as at least
  261.            one of the destinations in the address/mask pair is
  262.            determined to be reachable via OSPF; it MUST stop advertising
  263.            the route containing the set of reachable destinations when
  264.            none of the destinations in the address/mask pair is
  265.            reachable via OSPF.
  266.  
  267.       4.   The network administrator MUST be able to statically
  268.            configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute to
  269.            be used for any route.
  270.  
  271.            o    The default MUST be to omit the MULTI_EXIT_DISC in the
  272.                 route advertised via BGP/IDRP.
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Varadhan, Hares, Rekhter                                        [Page 5]
  279.  
  280. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  281.  
  282.  
  283.       5.   An implementation of BGP/IDRP and OSPF on an ASBR MUST have a
  284.            mechanism to set up a minimum amount of time that must elapse
  285.            between the learning of a new address/mask pair via OSPF and
  286.            subsequent advertisement of the address/mask pair via
  287.            BGP/IDRP to the external neighbours.
  288.  
  289.            o    The default value for this setting MUST be 0, indicating
  290.                 that the address/mask pair is to be advertised to the
  291.                 neighbour BGP/IDRP peers instantly.
  292.  
  293.                 Note that BGP and IDRP mandate a mechanism to dampen the
  294.                 inbound advertisements from adjacent neighbours.  See
  295.                 the variable MinRouteAdvertisementInterval in section
  296.                 9.2.3.1, [BGP-4] or in section 7.17.3.1, [IS10747].
  297.  
  298.       6.   LOCAL_PREF is not used to export OSPF information into
  299.            BGP/IDRP.
  300.  
  301.    2.2.  Importing BGP/IDRP information into OSPF
  302.  
  303.       1.   BGP/IDRP implementations SHOULD allow an AS to control
  304.            announcements of BGP/IDRP learned set of reachable
  305.            destinations into OSPF.  Implementations SHOULD support such
  306.            control with the granularity of a single destination.
  307.  
  308.            Implementations SHOULD also support such control with the
  309.            granularity of an autonomous system, where the autonomous
  310.            system may be either the autonomous system that originated
  311.            the information or the autonomous system that advertised the
  312.            information to the local system (adjacent autonomous system).
  313.  
  314.            o    The default MUST be to import nothing from BGP/IDRP into
  315.                 OSPF.  Administrators must configure every destination
  316.                 they wish to import.
  317.  
  318.                 A configuration parameter MAY allow an administrator to
  319.                 configure an ASBR to import all the set of reachable
  320.                 destinations from BGP/IDRP into the OSPF routing domain.
  321.  
  322.       2.   The administrator MUST be able to configure the OSPF cost and
  323.            the OSPF metric type of every destination imported into OSPF.
  324.  
  325.            o    The OSPF cost MUST default to the LOCAL_PREF value; the
  326.                 OSPF metric type MUST default to type 2.
  327.  
  328.       3.   Information learned via BGP/IDRP from peers within the same
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Varadhan, Hares, Rekhter                                        [Page 6]
  335.  
  336. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  337.  
  338.  
  339.            AS MUST not be imported into OSPF.
  340.  
  341.       4.   The ASBR MUST never generate a default destination into the
  342.            OSPF routing domain unless explicitly configured to do so.
  343.  
  344.            A default destination is a set of all possible destinations.
  345.            By convention, it is represented as a prefix of 0 length or a
  346.            mask of all zeroes.
  347.  
  348.            A possible criterion for generating default into an IGP is to
  349.            allow the administrator to specify a set of (set of reachable
  350.            destinations, PATH, default cost, default type) tuples.  If
  351.            the ASBR learns of at least one of the destinations in the
  352.            set of reachable destinations, with the corresponding PATH,
  353.            then it generates a default destination into the OSPF routing
  354.            domain, with the appropriate cost and type.  The lowest cost
  355.            route will then be injected into the OSPF routing domain.
  356.  
  357.            This is the recommended method for originating default
  358.            destinations in the OSPF routing domain.
  359.  
  360.       5.   Note that [RFC1247] requires the network number to be used as
  361.            the Link State ID.  This will produce a conflict if the ASBR
  362.            tries to import two destinations, differing only in their
  363.            prefix length.  An implementation conforming to [RFC1247]
  364.            MUST, in this case, drop the more specific route, i.e. the
  365.            route corresponding to the longer prefix in the reachability
  366.            information.  The OSPF WG is working on revising [RFC1247].
  367.            The revised version will incorporate hooks to handle the
  368.            conflict.
  369.  
  370.       6.   MULTI_EXIT_DISC is not used to import BGP/IDRP information
  371.            into OSPF.
  372.  
  373. 3.  BGP/IDRP Identifier and OSPF router ID
  374.  
  375.    The BGP/IDRP identifier MUST be the same as the OSPF router id at all
  376.    times that the router is up.
  377.  
  378.    Note that [BGP-4] requires that the BGP identifier be an address
  379.    assigned to the BGP speaker.
  380.  
  381.    In the case of IDRP, the IDRP protocol does not explicitly carry the
  382.    identity of the IDRP speaker.  An implicit notion of the identity of
  383.    the IDRP speaker can be obtained by examining the source address in
  384.    the IP packets carrying the IDRP information.  Therefore, all IDRP
  385.    speakers participating in the OSPF protocol MUST bind the IDRP
  386.    identifier to be the address of the OSPF router id.
  387.  
  388.  
  389.  
  390. Varadhan, Hares, Rekhter                                        [Page 7]
  391.  
  392. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  393.  
  394.  
  395.    This characteristic is required for two reasons.
  396.  
  397.      i    Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
  398.           belong to the same autonomous system.
  399.  
  400.  
  401.                                      +-----+
  402.                                      | RT3 |
  403.                                      +-----+
  404.                                         |
  405.  
  406.                           Autonomous System running OSPF
  407.  
  408.                                  /               \
  409.  
  410.                              +-----+          +-----+
  411.                              | RT1 |          | RT2 |
  412.                              +-----+          +-----+
  413.  
  414.  
  415.           Both RT1 and RT2 can reach an external destination X and
  416.           import this information into the OSPF routing domain.  RT3 is
  417.           advertising this information about destination X to other
  418.           external BGP/IDRP speakers.  If RT3 has equal cost routes to
  419.           RT1 and RT2, then RT3 must convert the PATH into a BGP AS_SET
  420.           or IDRP RD_SET to advertise to other external speakers; else
  421.           RT3 must use the OSPF router ID to determine whether it is
  422.           using RT1 or RT2 to forward packets to destination X and hence
  423.           build the correct PATH to advertise to other external
  424.           speakers.
  425.  
  426.           More precisely, RT3 MUST determine which ASBR it is using to
  427.           reach destination X to generate the corresponding network
  428.           layer reachability information for further advertisement to
  429.           external BGP/IDRP peers in the following manner:
  430.  
  431.           o    If RT3 has equal cost routes to RT1 and RT2, then, RT3
  432.                MUST merge the PATH through RT1 and RT2 into a SET.
  433.  
  434.           o    Otherwise, RT3 MAY merge the PATH through RT1 and RT2, or
  435.                RT3 MUST determine which ASBR it is using to reach
  436.                destination X by matching the OSPF router ID for its
  437.                route to destination X with the BGP identifier of one of
  438.                the ASBRs, or the IP source address of the IDRP protocol
  439.                packet from one of the ASBRs.
  440.  
  441.           It MAY then generate the corresponding network layer
  442.           reachability information for further advertisement to external
  443.  
  444.  
  445.  
  446. Varadhan, Hares, Rekhter                                        [Page 8]
  447.  
  448. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  449.  
  450.  
  451.           BGP/IDRP peers.
  452.  
  453.      ii   It will be convenient for the network administrator looking at
  454.           an ASBR to correlate different BGP/IDRP and OSPF information
  455.           based on the identifier.
  456.  
  457. 4.  Setting OSPF tags, ORIGIN and PATH attributes
  458.  
  459.    The OSPF external route tag is a ``32-bit field attached to each
  460.    external route . . . It may be used to communicate information
  461.    between AS boundary routers; the precise nature of such information
  462.    is outside the scope of [the] specification.''[RFC1247]
  463.  
  464.    OSPF imports information from various routing protocols at all its
  465.    ASBRs.  In some instances, it is possible to use protocols other than
  466.    EGP or BGP across autonomous systems.  It is important, in BGP/IDRP,
  467.    to differentiate between reachable destinations that are external to
  468.    the OSPF routing domain but must be considered internal to the AS, as
  469.    opposed to reachable destinations that are external to the AS.
  470.  
  471.    Reachable destinations that are internal to the AS and that may or
  472.    may not be external to the OSPF routing domain will not come to the
  473.    various BGP/IDRP speakers from other BGP/IDRP speakers within the
  474.    same autonomous system via BGP/IDRP.  Therefore, ASBRs running
  475.    BGP/IDRP must have knowledge of this class of reachable destinations
  476.    so that they can advertise these destinations to the various external
  477.    AS without waiting for BGP/IDRP updates from other BGP/IDRP speakers
  478.    within the same autonomous system about these destinations.
  479.  
  480.    Additionally, in the specific instance of an AS intermixing routers
  481.    running EGP and BGP/IDRP as external gateway routing protocols, using
  482.    OSPF as an IGP, then within the autonomous system, it may not be
  483.    necessary to run BGP/IDRP with every ASBR running EGP and not running
  484.    BGP/IDRP, if this information can be carried in the OSPF tag field.
  485.  
  486.    We use the external route tag field in OSPF to intelligently set the
  487.    ORIGIN and PATH attributes in BGP/IDRP.  These attributes are well-
  488.    known, mandatory attributes in the respective protocols.  The exact
  489.    mechanism for setting the tags is defined below.
  490.  
  491.    The tag is broken up into sub-fields shown below.  The various sub-
  492.    fields specify the characteristics of the set of reachable
  493.    destinations imported into the OSPF routing domain.
  494.  
  495.    The high bit of the OSPF tag is known as the ``Automatic'' bit.  When
  496.    this bit is set to 1, the following sub-fields apply:
  497.  
  498.  
  499.  
  500.  
  501.  
  502. Varadhan, Hares, Rekhter                                        [Page 9]
  503.  
  504. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  505.  
  506.  
  507.  
  508.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  509.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  510.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  511.      |a|c|p l|     ArbitraryTag      |       AutonomousSystem        |
  512.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  513.  
  514.  
  515.      a    is 1 bit called the Automatic bit, indicating that the
  516.           Completeness and PathLength bits have been generated
  517.           automatically by a router.  The meaning of this characteristic
  518.           and its setting are defined below.
  519.  
  520.      c    is 1 bit of Completeness information.  The meaning of this
  521.           characteristic and its settings are defined below.
  522.  
  523.      pl   are 2 bits of PathLength information.  The meaning of this
  524.           characteristic and its setting are defined below.
  525.  
  526.      ArbitraryTag
  527.           is 12 bits of tag information, which defaults to 0 but can be
  528.           configured to anything else.
  529.  
  530.      AutonomousSystem (or ``AS'')
  531.           is 16 bits, indicating the AS number corresponding to the set
  532.           of reachable destinations, 0 if the set of reachable
  533.           destinations is to be considered as part of the local AS.
  534.  
  535.           local_AS
  536.                The term `local_AS' refers to the AS number of the local
  537.                OSPF routing domain.
  538.  
  539.           next_hop_AS
  540.                `next_hop_AS' refers to the AS number of an external BGP
  541.                peer.
  542.  
  543.      When the Automatic bit is set to 0, the following sub-fields apply:
  544.  
  545.       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  546.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  547.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  548.      |a|                          LocalInfo                          |
  549.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  550.  
  551.  
  552.      a    is 1 bit called the Automatic bit, set to 0.
  553.  
  554.      LocalInfo
  555.  
  556.  
  557.  
  558. Varadhan, Hares, Rekhter                                       [Page 10]
  559.  
  560. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  561.  
  562.  
  563.           is 31 bits of an arbitrary value, manually configured by the
  564.           network administrator.
  565.  
  566.      The format of the tag for various values of the characteristics
  567.      bits is defined below.
  568.  
  569.    4.1.  Semantics of the characteristics bits
  570.  
  571.       The Completeness and PathLength characteristics bits define the
  572.       characteristic of the set of reachable destinations imported into
  573.       OSPF from other ASBRs in the autonomous system.  This setting is
  574.       then used to set the ORIGIN and PATH attributes when re-exporting
  575.       these reachable destinations to an external BGP/IDRP speaker.
  576.  
  577.       o    The Automatic characteristic bit is set when the Completeness
  578.            and PathLength characteristics bits are automatically set by
  579.            a border router.
  580.  
  581.            For backward compatibility, the Automatic bit must default to
  582.            0 and the network administrator must have a mechanism to
  583.            enable automatic tag generation.  Nothing must be inferred
  584.            about the characteristics of the OSPF address/mask pair from
  585.            the tag bits, unless the tag has been automatically
  586.            generated.
  587.  
  588.       o    The Completeness characteristic bit is set when the source of
  589.            the incoming route is known precisely, for instance, from an
  590.            IGP within the local autonomous system or EGP at one of the
  591.            autonomous system's boundaries.  It refers to the status of
  592.            the path information carried by the routing protocol.
  593.  
  594.       o    The PathLength characteristic sub-field is set depending on
  595.            the length of the PATH that the protocol could have carried
  596.            when importing the reachability information into the OSPF
  597.            routing domain.  The length bits will indicate whether the
  598.            PATH attribute for the length is zero, one, or greater than
  599.            one.
  600.  
  601.            Reachable destinations imported from an IGP will usually have
  602.            a PATH of length of 0, reachable destinations imported from
  603.            an EGP will have an PATH of length 1, BGP/IDRP and routing
  604.            protocols that support complete path information, either as
  605.            BGP AS_PATHs or IDRP routing domain paths(RD_PATHs), will
  606.            indicate a path greater than 1.
  607.  
  608.            The OSPF tag is not wide enough to carry path information
  609.            about reachable destinations that have an associated
  610.            PathLength greater than one.  Path information about these
  611.  
  612.  
  613.  
  614. Varadhan, Hares, Rekhter                                       [Page 11]
  615.  
  616. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  617.  
  618.  
  619.            destinations will have to be carried via BGP/IDRP to other
  620.            ASBRs with the same autonomous system.  Such destinations
  621.            must not be exported from OSPF into BGP/IDRP.
  622.  
  623.       In the following sections, the code YES will have value 1, and the  |
  624.       code NO will have value 0.
  625.  
  626.    4.2.  Configuration parameters for setting the OSPF tag
  627.  
  628.       o    There MUST be a mechanism to enable automatic generation of
  629.            the tag characteristic bits.
  630.  
  631.       o    Configuration of an ASBR running OSPF MUST include the
  632.            capability to associate a tag value, for the ArbitraryTag, or
  633.            LocalInfo sub-field of the OSPF tag, with each instance of a
  634.            routing domain.
  635.  
  636.       o    Configuration of an ASBR running OSPF MUST include the
  637.            capability to associate an AS number with each instance of a
  638.            routing domain.
  639.  
  640.            Associating an AS number with an instance of an IGP is
  641.            equivalent to flagging those set of reachable destinations
  642.            imported from the IGP to be external destinations outside the
  643.            local autonomous system.
  644.  
  645.            Specifically, when the IGP is RIP[RFC1058], it SHOULD be
  646.            possible to associate a tag and/or an AS number with every
  647.            interface running RIP on the ASBR.
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670. Varadhan, Hares, Rekhter                                       [Page 12]
  671.  
  672. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  673.  
  674.  
  675.       4.3.  Manually configured tags
  676.  
  677.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  678.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  679.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  680.       |0|                          LocalInfo                          |
  681.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  682.  
  683.          This tag setting  corresponds  to  the  administrator  manually
  684.          setting   the  tag  bits.   Nothing  MUST  inferred  about  the
  685.          characteristics  of   the   set   of   reachable   destinations
  686.          corresponding to this tag setting.
  687.  
  688.          For backward compatibility  with  existing  implementations  of
  689.          OSPF  currently deployed in the field, this MUST be the default
  690.          setting  for  importing  destinations  into  the  OSPF  routing
  691.          domain.   There  MUST  be  a  mechanism to enable automatic tag
  692.          generation for imported destinations.
  693.  
  694.          The OSPF tag to BGP/IDRP attribute mappings for these reachable
  695.          destinations MUST be
  696.  
  697.          Automatic=NO, LocalInfo=Arbitrary_Value =>                       |
  698.                                            ORIGIN=<EGP>, PATH=<local_AS>  |
  699.  
  700.    4.4.  Automatically generated tags
  701.  
  702.       4.4.1. Destinations with incomplete path information, PathLength =
  703.          0
  704.  
  705.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  706.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  707.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  708.       |1|0|0|0|     ArbitraryTag      |       AutonomousSystem        |
  709.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  710.  
  711.          These are reachable destinations imported from routing
  712.          protocols with incomplete path information and cannot or may
  713.          not carry the neighbour AS or AS path (and hence the IDRP
  714.          RD_PATH) as part of the routing information.
  715.  
  716.          The OSPF tag to BGP/IDRP attribute mappings for these
  717.          destinations MUST be
  718.  
  719.          Automatic=YES, Completeness=NO, PathLength=00, AS=0 =>
  720.                                            ORIGIN=<EGP>, PATH=<local_AS>
  721.  
  722.  
  723.  
  724.  
  725.  
  726. Varadhan, Hares, Rekhter                                       [Page 13]
  727.  
  728. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  729.  
  730.  
  731.       4.4.2. Destinations with incomplete path information, PathLength =
  732.          1
  733.  
  734.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  735.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  736.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  737.       |1|0|0|1|     ArbitraryTag      |       AutonomousSystem        |
  738.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  739.  
  740.          These are reachable destinations imported from routing
  741.          protocols with incomplete path information.  The neighbour AS
  742.          (and therefore IDRP RD) is carried in the routing information.
  743.  
  744.          The OSPF tag to BGP/IDRP attribute mappings for these
  745.          destinations MUST be
  746.  
  747.          Automatic=YES, Completeness=NO, PathLength=01, AS=<next_hop_AS>
  748.                            => ORIGIN=<EGP>, PATH=<local_AS, next_hop_AS>
  749.  
  750.          This setting SHOULD be used for importing reachable
  751.          destinations from EGP into the OSPF routing domain.  This
  752.          setting MAY also be used when importing reachable destinations
  753.          from BGP/IDRP whose ORIGIN=<EGP> and PATH=<next_hop_AS>; if the
  754.          BGP/IDRP learned route has no other transitive attributes, then
  755.          its propagation via BGP/IDRP to ASBRs internal to the
  756.          autonomous system MAY be suppressed.
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782. Varadhan, Hares, Rekhter                                       [Page 14]
  783.  
  784. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  785.  
  786.  
  787.       4.4.3. Destinations with incomplete path information, PathLength
  788.          >= 1
  789.  
  790.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  791.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  792.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  793.       |1|0|1|0|     ArbitraryTag      |       AutonomousSystem        |
  794.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  795.  
  796.          These are reachable destinations imported from routing
  797.          protocols with truncated path information.
  798.  
  799.          The OSPF tag to BGP/IDRP attribute mappings for these
  800.          destinations MUST be
  801.  
  802.          Automatic=YES, Completeness=NO, PathLength=10, AS=don't care
  803.  
  804.          These are imported by a border router, which is running
  805.          BGP/IDRP to a stub domain, and not running BGP/IDRP to other
  806.          ASBRs in the same autonomous system.  This causes a truncation
  807.          of the PATH.  These destinations MUST not be re-exported into
  808.          BGP/IDRP at another ASBR.
  809.  
  810.       4.4.4. Destinations with complete path information, PathLength = 0
  811.  
  812.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  813.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  814.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  815.       |1|1|0|0|     ArbitraryTag      |       AutonomousSystem        |
  816.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  817.  
  818.          These are reachable destinations imported from routing
  819.          protocols with either complete path information or are known to
  820.          be complete through means other than that carried by the
  821.          routing protocol.
  822.  
  823.          The OSPF tag to BGP/IDRP attribute mappings for these
  824.          destinations MUST be
  825.          Automatic=YES, Completeness=YES, PathLength=00, AS=00
  826.                                         => ORIGIN=<IGP>, PATH=<local_AS>
  827.          This SHOULD be used for importing reachable destinations into
  828.          OSPF from an IGP.
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838. Varadhan, Hares, Rekhter                                       [Page 15]
  839.  
  840. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  841.  
  842.  
  843.       4.4.5. Destinations with complete path information, PathLength = 1
  844.  
  845.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  846.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  847.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  848.       |1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
  849.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  850.  
  851.          These are reachable destinations imported from routing
  852.          protocols with either complete path information, or are known
  853.          to be complete through means other than that carried by the
  854.          routing protocol.  The routing protocol also has additional
  855.          information about the next hop AS or RD, the destination was
  856.          learned from.
  857.  
  858.          The OSPF tag to BGP/IDRP attribute mappings for these
  859.          destination MUST be
  860.  
  861.          Automatic=YES, Completeness=YES, PathLength=01, AS=next_hop_AS
  862.                            => ORIGIN=<IGP>, PATH=<local_AS, next_hop_AS>
  863.  
  864.          This setting SHOULD be used when the administrator explicitly
  865.          associates an AS number with an instance of an IGP.  This
  866.          setting MAY also be used when importing reachable destinations
  867.          from BGP/IDRP whose ORIGIN=<IGP> and PATH=<next_hop_AS>; if the
  868.          BGP/IDRP learned route has no other transitive attributes, then
  869.          its propagation via BGP/IDRP to other ASBRs internal to the
  870.          autonomous system MAY be suppressed.
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894. Varadhan, Hares, Rekhter                                       [Page 16]
  895.  
  896. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  897.  
  898.  
  899.       4.4.6. Destinations with complete path information, PathLength >=1
  900.  
  901.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  902.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  903.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  904.       |1|1|1|0|     ArbitraryTag      |       AutonomousSystem        |
  905.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  906.  
  907.          These are reachable destinations imported from routing
  908.          protocols with complete path information and carry the AS path
  909.          information as part of the routing information.
  910.  
  911.          The OSPF tag MUST be set to
  912.  
  913.          Automatic=YES, Completeness=YES, PathLength=10, AS=don't care
  914.  
  915.          These destinations MUST not be exported into BGP/IDRP because
  916.          these destinations are already imported from BGP/IDRP into the
  917.          OSPF RD.  Hence, it is assumed that the BGP/IDRP speaker will
  918.          convey this information to other BGP/IDRP speakers within the
  919.          same autonomous system via BGP/IDRP.  As ASBR learning of such
  920.          a destination MUST wait for the BGP update from its internal
  921.          neighbours before advertising it to external BGP/IDRP peers.
  922.  
  923.          Note that an implementation MAY import reachable destinations
  924.          from BGP/IDRP with a path length of 1 and no other transitive
  925.          attributes directly into OSPF and not send these routes via
  926.          BGP/IDRP to ASBRs within the same autonomous system.  In this
  927.          situation, it MUST use tag settings corresponding to 4.4.2, or
  928.          4.4.5.
  929.  
  930.    4.5.  Miscellaneous tag settings
  931.  
  932.        0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  933.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  934.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  935.       |1|x|1|1|              Reserved  for  future  use               |
  936.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  937.  
  938.       The value of PathLength=11 is reserved during automatic tag
  939.       generation.  Routers must not generate such a tag when importing
  940.       reachable destinations into the OSPF routing domain.  ASBRs must
  941.       ignore tags which indicate a PathLength=11.
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950. Varadhan, Hares, Rekhter                                       [Page 17]
  951.  
  952. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  953.  
  954.  
  955.    4.6.  Summary of the tag sub-field setting
  956.  
  957.       The following table summarizes the various combinations of
  958.       automatic tag settings for the Completeness and PathLength sub-
  959.       field of the OSPF tag and the default behaviour permitted for each
  960.       setting.
  961.  
  962.                   Completeness := 0 | 1
  963.                   PathLength := 00 | 01 | 10 | 1
  964.                   ORIGIN := <IGP> | <EGP>
  965.                   PATH := valid AS path settings as defined in BGP [BGP-4],
  966.                               and IDRP for IP[IDRP].
  967.  
  968. PathLength ==> 00               01                   10                11
  969. Completeness
  970.   ||     +--------------------------------------------------------------------
  971.   vv     |
  972.   =  NO  |    <EGP>            <EGP>             never export       reserved
  973.          |  <local_AS>  <local_AS,next_hop_AS>
  974.          |
  975.   = YES  |    <IGP>            <IGP>             out of band        reserved
  976.          |  <local_AS>  <local_AS,next_hop_AS>
  977.          |
  978.  
  979.       The "out of band" in the table above implies that OSPF will not be
  980.       able to carry everything that BGP needs in its routing
  981.       information.  Therefore, some other means must be found to carry
  982.       this information.  In BGP, this is done by running BGP to other
  983.       ASBRs within the same autonomous system.
  984.  
  985. 5.  Setting OSPF Forwarding Address and BGP/IDRP NEXT_HOP attribute
  986.  
  987.    Forwarding addresses are used to avoid extra hops between multiple
  988.    routers that share a common network and that speak different routing
  989.    protocols with each other on the common network.
  990.  
  991.    Both BGP/IDRP and OSPF have equivalents of forwarding addresses.  In
  992.    BGP and IDRP, the NEXT_HOP attribute is a well-known, mandatory
  993.    attribute.  OSPF has a Forwarding address field.  We will discuss how
  994.    these are to be filled in various situations.
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006. Varadhan, Hares, Rekhter                                       [Page 18]
  1007.  
  1008. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  1009.  
  1010.  
  1011.  
  1012.    Consider the 4 router situation below:
  1013.  
  1014.    RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
  1015.    RT1 and RT3 are talking BGP/IDRP with each other.  RT3 and RT4 are
  1016.    talking OSPF with each other.
  1017.  
  1018.             +-----+                 +-----+
  1019.             | RT1 |                 | RT2 |
  1020.             +-----+                 +-----+
  1021.                |                       |            common network
  1022.             ---+-----------------------+--------------------------
  1023.             <BGP/IDRP> |                       |
  1024.                     +-----+     <OSPF>      +-----+
  1025.                     | RT3 |                 | RT4 |
  1026.                     +-----+                 +-----+
  1027.  
  1028.  
  1029.      - Importing a reachable destination into OSPF:
  1030.           When importing a destination from BGP/IDRP into OSPF, RT3 MUST
  1031.           always fill the OSPF Forwarding Address with the BGP/IDRP
  1032.           NEXT_HOP attribute for the destination.
  1033.  
  1034.      - Exporting a reachable destination into BGP:
  1035.           When exporting set of reachable destinations internal to the
  1036.           OSPF routing domain from OSPF to BGP/IDRP, if all the
  1037.           destinations in the set of reachable destinations are through
  1038.           RT4, then RT3 MAY fill the NEXT_HOP attribute for the set of
  1039.           reachable destinations with the address of RT4.  This is to
  1040.           avoid requiring packets to take an extra hop through RT3 when
  1041.           traversing the AS boundary.  This is similar to the concept of
  1042.           indirect neighbour support in EGP[RFC888, RFC827].
  1043.  
  1044. 6.  Changes from the BGP 3 - OSPF interactions document
  1045.  
  1046.      o    The use of the term "route" has attained a more complicated
  1047.           structure in BGP 4.  This document follows the constraint in
  1048.           the manner shown below:
  1049.  
  1050.           -    The term "set of reachable destinations" is called a NLRI
  1051.                in [BGP-4].
  1052.  
  1053.           -    The term "route" in the BGP context refers to a set of
  1054.                reachable destinations, and the associated attributes for
  1055.                the set.
  1056.  
  1057.           -    The term "route" in the OSPF context refers to the set of
  1058.                reachable destinations, and the cost and the type to
  1059.  
  1060.  
  1061.  
  1062. Varadhan, Hares, Rekhter                                       [Page 19]
  1063.  
  1064. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  1065.  
  1066.  
  1067.                reach destinations.  This is to keep the definitions
  1068.                consistent in the document.
  1069.  
  1070.      o    The notion of exchanging reachability information between BGP
  1071.           4 and OSPF has been updated to handle variable length net mask
  1072.           information.
  1073.  
  1074.      o    The previous term INTER_AS_METRIC in BGP 3 has now been
  1075.           changed to MULTI_EXIT_DISC.
  1076.  
  1077.      o    The default metric to be used for importing BGP information
  1078.           into the OSPF RD is now the LOCAL_PREF attribute, instead of a
  1079.           constant value.
  1080.  
  1081.      o    Section 3 which requires an ASBR to match the OSPF tag
  1082.           corresponding to a route to the BGP Identifier, can cause
  1083.           potential loops if the AS has equal cost multipath routing
  1084.           amongst the ASBRs.  This scenario is outlined in the Appendix
  1085.           below.  This is fixed in BGP4 by requiring the ASBR seeing
  1086.           equal cost multi-path routes to merge the PATHs through the
  1087.           various ASBRs into appropriate SETs.
  1088.  
  1089.      o    BGP 4 requires that the BGP identifier be an address assigned
  1090.           to the BGP speaker.  This is dealt with in section 3.
  1091.  
  1092.      o    Section 5 on setting NEXT_HOP attributes and Forwarding
  1093.           Address field has been updated to account for variable length
  1094.           net information.
  1095.  
  1096.      o    This section, 6, has been added.
  1097.  
  1098. 7.  Security Considerations
  1099.  
  1100.    Security considerations are not discussed in this memo.
  1101.  
  1102. 8.  Acknowledgements
  1103.  
  1104.    We would like to thank Jeff Honig (Cornell University), John Moy
  1105.    (Proteon, Inc.), Tony Li (cisco Systems), Rob Coltun (Consultant),
  1106.    Dennis Ferguson (ANS, Inc.), and Phil Almquist (Consultant) for their
  1107.    help and suggestions in writing this document.
  1108.  
  1109.    We would also like to thank the countless number of people from the
  1110.    OSPF and BGP working groups who have offered numerous suggestions and
  1111.    comments on the different stages of this document.
  1112.  
  1113.    Thanks also to Bob Braden (ISI), whose suggestions on the earlier
  1114.    BGP-OSPF document, [RFC1403] were useful even for this one, and have
  1115.  
  1116.  
  1117.  
  1118. Varadhan, Hares, Rekhter                                       [Page 20]
  1119.  
  1120. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  1121.  
  1122.  
  1123.    been carried through.
  1124.  
  1125.    We would also like to thank OARnet, where one of the authors did most
  1126.    of his work on this document, before moving to USC to resurrect his
  1127.    PhD.
  1128. 9.  Bibliography
  1129.  
  1130.  
  1131. [RFC827]   Rosen, Eric C., ``Exterior Gateway Protocol (EGP)'', October
  1132.      1982.
  1133.  
  1134. [RFC888]   Seamonson, Linda J.; and Rosen, Eric C., ``'STUB' Exterior
  1135.      Gateway Protocol'', January 1984.
  1136.  
  1137. [RFC1058]  Hedrick, Charles, L., ``Routing Information Protocol'', June
  1138.      1988.
  1139.  
  1140. [RFC1122]  Braden, R.T., ed., ``Requirements for Internet hosts -
  1141.      communication layers'', October 1989.
  1142.  
  1143. [RFC1123]  Braden, R.T., ed., ``Requirements for Internet hosts -
  1144.      application and support'', October 1989.
  1145.  
  1146. [RFC1247]  Moy, John, ``The OSPF Specification  Version 2'', January
  1147.      1991.
  1148.  
  1149. [RFC1338]  Fuller, Vince; Li, Tony; Yu, Jessica; Varadhan, Kannan,
  1150.      ``Supernetting: an Address Assignment and Aggregation Strategy'',
  1151.      June 1992.
  1152.  
  1153. [RFC1403] Varadhan, Kannan; ``BGP OSPF Interaction''; January 1993.
  1154.  
  1155. [ROUTE-LEAKING]  Almquist, Philip, ``Ruminations on Route Leaking'', in
  1156.      preparation.
  1157.  
  1158. [NEXT-HOP]  Almquist, Philip, ``Ruminations on the Next Hop'', in
  1159.      preparation.
  1160.  
  1161. [BGP-4]  Rekhter, Yakov; and Li, Tony, Editors ``A Border Gateway
  1162.      Protocol 4 (BGP-4)'', in preparation.
  1163.  
  1164. [IDRP]  Hares, Susan; ``IDRP for IP'', in preparation
  1165.  
  1166. [IS10747]  ISO/IEC IS 10747 - Information Processing Systems -
  1167.      Telecommunications and Information Exchange between Systems -
  1168.      Protocol for Exchange of Inter-domain Routeing Information among
  1169.      Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993.
  1170.  
  1171.  
  1172.  
  1173.  
  1174. Varadhan, Hares, Rekhter                                       [Page 21]
  1175.  
  1176. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  1177.  
  1178.  
  1179. 10.  Appendix
  1180.  
  1181.                                        +--------+
  1182.                            X ----------| C1     |
  1183.                            |           |Domain C|
  1184.                            |           | C3  C2 |
  1185.                            |           +--------+
  1186.                            B             /   \
  1187.                             \           /     \
  1188.                              \         /      S
  1189.                               \       /      /
  1190.                                \     /      /
  1191.                              +--------+    /
  1192.                              | A1  A2 |   /
  1193.                              |Domain A|  /
  1194.                              |     A3 |-/
  1195.                              +--------+
  1196.  
  1197.  
  1198.    Given the domains, X, A, B, C and S, let domains A and C be running
  1199.    OSPF, and ASBRs A3 and C3 have equal cost multipath routes to A1, A2
  1200.    and C1, C2 respectively.  The picture above shows the internal
  1201.    structure of domains A and C only.
  1202.  
  1203.    During steady state, the following are the route advertisements:
  1204.  
  1205.      o    Domain B advertises to A path <B,X>
  1206.  
  1207.      o    ASBR A3 in domain A advertises path <A,B,X> to domain C, at
  1208.           ASBR C2.
  1209.  
  1210.      o    Domain C has two equal cost paths to X: one direct <C,X>, and
  1211.           another through A <C,A,B,X>
  1212.  
  1213.      o    BR C3 in domain C advertises to A2 path <C,X>
  1214.  
  1215.      o    Domain A has two equal cost paths to X: <A,C,X> and <A,B,X>
  1216.  
  1217.      Both C1 and C2 inject a route to X within the domain C, and
  1218.      likewise A1 and A2 inject a route to X within the domain A.  Since
  1219.      A3 and C3 see equal cost routes to X through A1, A2 and C1, C2
  1220.      respectively, a stable loop through ASBRs <A3, A2, C3, C2, A3>
  1221.      exists, which is used by these routers for load splitting with
  1222.      equal cost multi-path routing.
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230. Varadhan, Hares, Rekhter                                       [Page 22]
  1231.  
  1232. INTERNET DRAFT  (Expires March 25, 1993)                    September 93
  1233.  
  1234.  
  1235. 11.  Author's  Present Addresses
  1236.  
  1237.       Kannan Varadhan
  1238.       Graduate Student, USC
  1239.       Dept. of Computer Science,
  1240.       University of Southern California,
  1241.       Los Angeles, California.
  1242.       Phone: (310) 842 8144
  1243.       e-mail: kannan@caldera.usc.edu
  1244.  
  1245.       Susan Hares
  1246.       e-mail: skh@merit.edu
  1247.  
  1248.       Yakov Rekhter
  1249.       T.J. Watson Research Center, IBM Corporation
  1250.       P.O. Box 218
  1251.       Yorktown Heights, NY 10598
  1252.       Phone: (914) 945-3896
  1253.       e-mail: yakov@watson.ibm.com
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286. Varadhan, Hares, Rekhter                                       [Page 23]
  1287.  
  1288.